So, this is being recorded for YouTube and you can find that by just simply googling YouTube and Genetic Genealogy Ireland and that will bring you to our dedicated YouTube channel. Most of the presentations that you have seen this weekend are going to be up there. So that's the majority of the presentations and it's a great resource for everybody who is not able to make it to the conference in Dublin themselves. Now, in terms of identifying World War I soldiers, I'm going to talk about the identification process itself. I'll give you the example of fromel which was when 250 soldiers were found in the mass grave back in 2009. We'll talk about whether the public databases that we are creating as genetic genealogists can actually help the identification process and then I'll say a few words about creating your own memorial using genealogy and genetic genealogy. First off, John Redmond encouraged a lot of Irish people to join up in the war effort in 1914 when World War I broke out. A lot of Irish men joined for the glory of Ireland and there were many Irish heroes who fought in World War I and one of the most famous was Sergeant Michael O'Leary who became part of the general World War I propaganda at the time how he defeated 10 Germans single-handedly as one against the thousands that type of thing. So there was a lot of involvement of Ireland in World War I. A million people died in action, one over a million men, 800 women and 338,000 of those million people who died are still missing from the British and Commonwealth forces and the majority of those will be lying somewhere on the Western Front. Over 200,000 Irishmen fought in the British Army and this is a map that breaks down the more than 35,000 Irish men that were killed during World War I 10% of them at the at the Somme 3,500 at the Somme, 2,000 from the 36th Ulster Division and 1,200 from the 16th Irish Division and this is a breakdown by county of the various known fatalities that happened of Irish men fighting in World War I. So how many soldiers in the British Army do not have a known grave? Well these days are based from March 2009 and they reckon that the those that are buried in named graves amount to over 500,000. No known graves but listed on memorial to the missing another 500,000 and of these about 187,000 are buried in unmarked graves or unidentifiable graves and therefore those that are not buried at all amount to about 338,000. So those men are still lying in the green fields of France and we're finding about 30 bodies per year so if it took a thousand years we might get somewhere near finding all of those men. Here's just a map of the Western Front which stretched from the French Belgium border on the coast of Stend going down through northern France over to northwestern France over to the German border just south of Luxembourg and all the way down to Switzerland and these are for some of the major battles occurred. Here's the river Somme here that's where a large proportion of the World War I casualties took place and there's also a Google map which actually shows you where recovery of servicemen has been found and you can see that it mirrors the Western Front that many of them were found on the Western Front and this is where various people were discovered over various periods of time. So these remains are being discovered all the time somewhere between 30 to 60 soldiers remains are being discovered every year during routine farm work during road widening schemes during excavation for building new buildings. So for example in April 2016 there were 19 bodies recovered two of them were deemed to be German nine were deemed to be nine Commonwealth soldiers only two have been identified so far you can see here that the badge says Royal Warwickshire so they were able to identify the regiment for the Commonwealth soldiers that were found and this is just one example of these annual discoveries that occur as farmers are doing their routine farm work. Now the usual process for managing these recovered remains is to contact the police first of all to find out whether it's a recent death and possibly a murder and if they come out and say no there's nothing recent about this it's probably war dead then the remains are first of all permission is given to recover the remains and that recovery process may be undertaken by the local army or archaeologists or even the person the original finder of the remains if it was part of an archaeological dig for example in Belgium then the police write a detailed report but if the discovery occurs in France where the majority of the finds will be then it's the Commonwealth War Grave Commission's exhumation officer who will take charge of coordinating the recovery and they'll also secure the artifacts and store the remains in especially designed mortuary they have for that purpose. Then perhaps the identity of the nationality can be confirmed and if the nationality can be confirmed then the Commonwealth War Grave Commission reports to the member government ministry defense so in the United Kingdom it's the JCCC in Germany it's the VDK if it is a British and Commonwealth soldier then the JCCC will coordinate everything to identify that particular soldier they'll be looking to identify the nationality the regiments and the individual himself and if that individual is identified then the family will be traced and a funeral will be organized. That sounds like a very simple process but an actual fact it is hugely complicated. The process for identifying the remains is coordinated in the UK by the Ministry of Defense specifically the sub-team the service personnel and veterans agency specifically the sub-sub-team the joint casualty and compassionate care center the sub-sub-sub-team historic casualty and deceased estate casework team and the sub-sub-sub-sub-team which deals with historic casualties and war dead that consists of two people if you're getting the impression that this is quickly becoming an impossible task I think you would probably be heading in the right direction you know if there are 30 bodies discovered every year then two people that's 15 bodies per person 12 months in a year they have less than four weeks to identify each individual that's if they're working at it full-time so you can see that there is a huge amount of work potentially that falls on the shoulders of these two people so what happens when you discover 250 soldiers in a mass grave chaos absolutely chaos the recovery team may involve a forensic archaeologist who employs crime scene investigation like procedures I couldn't include a forensic anthropologist like Rene Gaper who was speaking to us yesterday about the Barrymore project and that forensic anthropologist will look to maybe to find the age the height the battle wounds and he's distinguishing features like a broken arm a broken leg that has healed previously there may also be a military historian involved a photographer a project manager and the aim is to identify nationality regiment and the individual soldier himself here's an example of some of the finds so here we have an entire tank that has been discovered here is some ammunition that has been discovered that might tell you the nationality of the soldier I'm no expert on ammunition but is that a Luger it is okay so that's probably a German soldier that has been discovered the trench tools that they use to dig the trenches can also tell you the identity of the nationality of the soldier and here we have Tony Robinson probably with British French digging tools I'm not sure boots footwear clothing buttons can tell you the regiment that the soldier belongs to and badges and here we have again the Royal Warwickshire badge discovered in April of this year dog tags now dog tags were introduced in August 1914 as a single dog tag so a soldier dies he has his dog tag on the Germans come along and they take the dog tag to give it to the Red Cross so the Red Cross can give it to the family so they know the soldier has died what's left on the soldier nothing the two dog tag system was introduced in September 1916 which was three months after the Battle of Ramelle so it was too late for from El so in from El it was the one dog tag system approach where that was used and they couldn't identify the soldiers by dog tags in from El as a result of that here's an example of some of the artifacts that might be found with the soldier we have up here on the top left maybe an ink bottle here's a spoon here's a helmet here's a tin these are belt buckles I think here and that can be quite I that can identify the nationality of the soldier because they can be quite distinctive here's a pipe here's a brush here's a book maybe so these are the kind of artifacts that might be found with the soldier and the process for identifying these remains is first of all looking for nationality and regiment and for this historical war records that detail the troop movements are very very important and also artifacts found with or near the remains very very important for identifying nationality and regiment sometimes the service number will be on the spoon so Michelle is saying that John Morrison earlier this year Michelle was involved with the identification and the service number was actually on the spoon so that's quite a rare case and I should say that Michelle who will be featuring in this presentation is one of the genealogists that helped identify the soldiers in the mass grave in from L so and she did a very good presentation last year and I have a link to it in the slideshow so you'll be able to take that down if possible the individual has identified is a DNA sample taken well up until about April of this year apparently it was not but now apparently it is according to one of the great war forums one of those discussion groups that you have online but how the DNA is taken what DNA is taken and what analysis they do there's no information there's nothing on the official websites from the Commonwealth War Graves Commission or the JCCC to say just exactly what they are doing what the process is for DNA sampling and what kind of DNA they're actually taking the genealogy and the potential living relatives are then traced working with volunteer genealogists like Michelle and Mel Pax another one and there might be a couple of other genealogists around the UK that do this type of work but I think it's so important to emphasize that this is volunteer genealogists like you and me if the relatives can be contacted then DNA is taken from the relatives compared with the DNA you've got from the soldier and the identity is confirmed that way again it sounds incredibly easy you'll see how difficult it is from from El question at the back we collect why DNA and mitochondrial DNA apparently from what we did it in the from El project and when they say they are collecting DNA I'm assuming it's why DNA as well as mitochondrial DNA I don't know if they're collecting autosomal DNA as well which is all the other chromosomes so like I say we just don't know because there's no information out there war records are a bit of a problem most servicemen swear about can be located given a name a regiment and a date so if you have a relative who was in the British Army they're whereabouts can be located by a name a regiment and a date that's that's pretty good going and the military historian at Q in London is able to do that the servicemen's details exist for Canadian and Australian service files but the British records were burnt during the blitz in Second World War and only about I think it's a 70% of them remain or 70% of them were destroyed so it's about 60 70% of them were destroyed and it means that the servicemen the burnt records of the ones that survive not many so so it's difficult to actually get servicemen's details including age height nationality ethnicity date of birth that kind of thing there have been issues and concerned about the whole process expressed on a lot of these Great War forums World War one forums Facebook that type of thing primarily around insufficient efforts being made historically to identify these found remains the recovery of the remains sometimes the farmers do not report them because there's too much delay it's an inconvenience for their livelihood and it's a loss of income and in many cases the remains are just plowed over are their bulldozed and they're lost to them also the local laws and customs are not clearly stated or understood and if they are understood are they actually observed and enforced there's also major problem with trophy hunters some of whom can be very very aggressive Andy Robert Shaw talks about when he was on an archaeological dig recovering some soldiers a live bullet was taped to his windscreen of his car so there can be incredibly it's certainly in Russia I think there is a huge business in World War one memorabilia also the incentives to report soldiers remains have been tried previously with detrimental effects so for example you would get a bounty if you found a skeleton and reported it so people split the skeleton in two and got two bounties there's a reluctance to publicize the fines by the Commonwealth War Graves Commission and other Ministry of Defense's there's a lack of transparency as to the exact process and DNA is not routinely recovered from the remains prior to reburial at least historically is that still true according to one of the forums they're now collecting DNA since April of this year whether that is the case I'm not sure because there's nothing official so onto a prime example of the recovery process and the from El project and there is some information about the from El project online this is the Australian Army website we also have the Commonwealth War Graves Commission website so some of the information in this presentation has been gleaned from these websites there's also a very very very good documentary which features Michelle and you can see it on that particular link there at the bottom called finding the battalions the lost battalions which details the whole recovery process of from El but most of the information that I'll be giving you is from these two books remembering from El which was compiled by Julius Summers and includes accounts from various people that were involved in the project and also remember me to all which was published by Oxford Archaeology which was the archaeological group that was responsible for digging up the mass grave so battler from El took place on the 19th of July 1916 it was a diversionary tactic in conjunction with the battle of the psalm so they wanted to divert German attention away from the psalm onto from El and that maybe gives the advantage to the British troops at at the psalm over 5,000 Australian casualties occurred and it has gone down as the worst day in Australian military history 2,000 of them were killed 1,299 were missing there were 1,547 British casualties of whom about 500 were killed so you're looking at somewhere in the region of 2,500 people being killed during the battle of from El now a word about the numbers the numbers vary because people are not entirely sure just exactly how many people were killed during this time but the dead have been counted so for example at VC Corner Cemetery there's a memorial for 1,294 Australian soldiers who are missing presumed dead it was initially 1,299 but five of them were identified in the 1920s so now it's 1294 and the five names have been cemented so that they're no longer visible on the memorial there are 410 unidentified Australian soldiers buried in VC Corner Cemetery and in nearby cemeteries there's other unidentified Australian soldiers for example 266 in Rue David 142 in ration farm 22 in Rue Petillon 72 in Y farm so totaling it all up there are 1,131 unknown Australian burials in total from the battle of from El and that leaves 163 Australian Australian soldiers still missing and unaccounted for where are they and that was the question that was asked by a retired school teacher Lampus Iglesos and he started investing investigating these unaccounted for missing soldiers and he was joined in 2003 by Peter Barton a very well-known military historian who was also co-secretary of the all-party war graves and battle heritage group in the UK and then in 2006 the records indicated that there were mass graves for 400 dead dug behind pheasant wood near from El and that meant that if there were 163 Australians among the 400 dead there could be up to 240 British among those people in that mass grave and when Peter Barton presented this to the all-party war graves and battle heritage group in the House of Commons that's when the British really became involved in trying to find the missing of from El so in 2007 they located where the mass they thought the mass grave was and they did a geophysical survey which confirmed that there was eight mass graves in that area and the following year they did a limited excavation which confirmed that there were remains present and thereafter in 2009 they did a full-scale excavation of the mass grave and you can mass graves were buried by the Germans mass graves were dug by the Germans so immediately after the battle of from El and you can read about it as an issue 44 of war time but immediately after the battle for hygiene reasons the Germans would have dug these graves and would have put the bodies into the graves they were not dumped in the graves they were actually laid out extremely respectfully there were there were even two brothers put in side by side so this is the site of the mass grave in pheasant wood and the excavation took place between the 5th of May 2009 and the 16th of October 2009 it was a very warm summer and they had to wear these crime scene investigation like suits to avoid contamination the artifacts were logged the chain of custody was established and here's a variety of artifacts that they found in the area so here we have a bible with some of the passages underlined this is a boot which is actually quite unusual because the British boots were much more comfortable than the German boots so if the Germans found a British dead they would take the boots off and swap their boots because it was more comfortable for the for the Germans with the British boots here is a gold cross here is either a pocket watch or a compass with some engraving on the back but not enough engraving to actually give an identification of the person and of course the problem with these artifacts that have engravings on them is that was this the belonging of the actual soldier where it was found or did he say oh Billy's dead I must pick up his watch and tell his family and then he gets shot with Billy's watch so it wasn't possible to use these kind of artifacts for identification purposes here's a cardigan here's a very touching one it's a rosary beads here's a money pouch these are matches everybody smoked in those days these are matches this is a leather case for wire cutters to cut through the barbed wire this is a return ticket to Perth that was never used so altogether 250 remains were exhumed and DNA was collected first of all was collected from the people working on the site to form an elimination database all those people in those white suits that you saw they had their DNA tested to make sure that their DNA did not contaminate what they were excavating the collection was supervised by the Commonwealth War Graves Commission project manager and stored by the scene of crime officer then DNA samples were collected from the bodies of the scene again supervised by the scene of crime officer and transported to the DNA laboratory the forensics laboratory LGC forensics in London and they determined whether viable DNA could be extracted from the samples now the sort of samples that they took back in 2009 was a minimum of one tooth and one bone sample the tooth could be upper canine upper second molar the bones were metacarpals metatarsals those are the metacarpals in the hand metatarsals in the foot fibula is the outside of the leg the long bones like the the the femur and the humerus the radius and the ulna in the forearm a rib and of all else a femur so the femur was the last one because it's just so big and bulky and it had to be transported from France to London they also sometimes use soft tissue including hair Achilles tendon and even brain tissue so pretty gruesome stuff modern sampling in 2016 would dictate perhaps that the preferred area is the Petra's bone the inner ear because you get for up to 400 times the yield of DNA that you would get from these other bones the DNA that they did recover was viable they recovered it in low quantities and in a degraded form but it was sufficiently usable to obtain YSTOR and mitochondrial DNA profiles for all of the buried soldiers how many YSTOR markers were recovered probably 17 because they were using the Wi-Fi or 17 system to amplify the the DNA and extracted how many mitochondrial DNA markers were recovered I don't know because it's not actually reported in any of the sources that I've looked at in order to create a comparative DNA database remember we've got the elimination database for the workers working there to make sure that they're not contaminating then we've got the DNA from the soldiers themselves all 250 soldiers Y DNA and mitochondrial DNA now we need to compare the soldiers DNA to something that's going to help identify them and that's something is the DNA from their relatives from their family now 250 soldiers were recovered but we knew that 1,650 were missing and they had to belong to that list of 1,650 some of them are already buried in unknown graves or on marked graves on identified graves but we knew that the 250 soldiers in the mass grave belonged to a list of 1,650 soldiers so what did we do we needed a DNA sample from the families of the 250 so we had to trace the families of all 1,650 that were on the list of missing soldiers now you can see the enormity of the task and for this to fall on the shoulders of two people in the sub sub sub sub team of the ministry of defense it was a major major undertaking and they did very very well to do as well as they did they um well they did well to to deal with the barrage of information they were getting from the volunteer genealogists like Michelle and Mel Pack in the UK and various other people in Australia who were involved in the identification of the 1,650 genealogies of those soldiers on that list of missing and unaccounted for they wanted preferably informative DNA donors so it had to be on a on a on a Y line so that's father father father father a direct mail line and they also for the mitochondrial DNA they had to it had to be on a mother mother mother line going back towards the soldier or his parents or his grandparents or his great grandparents um and there preferably had to be two Y DNA samples from each family and two mitochondrial DNA samples from each family that meant we needed 6600 DNA donors to identify 250 soldiers an enormous task an absolutely enormous task this is an example of what an informative DNA donor looks like if we assume that this chap from World War I born in 1895 died in 1916 he would have been 20 years old um there's his parents there's his great grandparents and great grandparents if he had brothers who had sons who had sons who were still alive in in 2016 these would be informative Y DNA donors these are people that we could test because their Y DNA would have been inherited from the father of the soldier it would have come down that direct mail line for the mitochondrial DNA if the soldier had sisters they would have received the mitochondrial DNA from their mother passes on to their daughters who would have passed it on to their daughters or sons if any of these were still alive they would be candidates for mitochondrial DNA testing because the mitochondrial DNA has passed down along the direct female line to these relatives and the soldier himself if there were no brothers supposing the soldier had no brothers you go up a generation higher to a brother of his father and trace down that way and if there were no sisters you might have to go up two generations and then trace down look where you have to go back to you have to go back to 1800 in some of these genealogies to actually get informative DNA donors so sometimes it was an easy task sometimes it was an impossible task but the whole idea is to triangulate on this soldier with both Y DNA and mitochondrial DNA and the triangulation is important because we're not just using the Y DNA in isolation or the mitochondrial DNA in isolation we're using them both together to use Bayesian statistical probabilities which i'll show you shortly sorry leave that up for you to take a photograph so tracing the living relatives by was done by the Joint Casualty and Compassionate Centre in the UK or the unrecovered war casualties army in Australia they tried two methods the first method was publicity they put it in the papers they advertised it there was a petition for family to come forward who knew that they had relatives who fought in fromel that was successful in Australia it was not successful in the UK because fromel was well known in Australia and everybody in the UK had not heard about it there were local media reports on individual soldiers which did bring local families forward and there were road shows shows specifically in the UK that did help identify some of the soldiers families but the main method that was used to get informative DNA donors was the genealogy method and that meant that genealogists like Michelle tracked down soldiers from the list of 1650 the regimental groups and societies were very helpful and cooperative Mel Pack in the UK traced most of the British families along with Michelle and small teams of dedicated volunteer genealogists did most of this legwork and then sent this huge body of data to the two people working in the sub sub sub team of the Ministry of Defense so it was incredible incredible amount of work and it required an incredible amount of cooperation collaboration and communication and a lot of the time it worked and some of the time it worked well this is Michelle's presentation from a genetic genealogy island which was two years ago 2014 and you can see that on YouTube on the genetic genealogy island YouTube channel tracing living relatives was very successful and in most cases no possible genetic identification was achieved in only a very small number of cases either because the family was extinct and had died out or there was no informative relatives that survived there wasn't anybody on the direct male line there wasn't anybody on the direct female line so they couldn't get YDNA or mitochondrial DNA and in only a very very small number of cases the families were unwilling to donate the DNA that happened in three out of 277 families in the UK only YDNA and mitochondrial DNA was collected from these families as far as i can ascertain there was no autosomal DNA connected collected from these families but some of the DNA was actually collected from deceased people in the families from medical slides or biopsies that they'd had at the local hospital so there were extraordinary lengths gone to to achieve the outcome of this project also there was an expected NPE rate of about one to two percent NPE non-paternal event also known as not the parent expected either because of adoption or illegitimacy or infidelity and they were expecting a one to two percent non-paternal event rate they observed a two percent rate so they were bang on with that estimate the actual identification process itself involved a data analysis team headed by Professor Margaret Cox of Oxford Archeology then there was a co-chair in Dr Peter Jones and then they had subject matter experts in anthropology archaeology molecular genetics military history records and statistics as required this data analysis team would review all the data that have been collected not just the DNA data but also the artifactual data and the age and stature and anthropological data and then they would make a judgment on whether or not a particular soldier could be identified beyond reasonable doubt and i'll talk about the identification standards shortly and then they would make a recommendation to the joint identification board so the data analysis team were the experts the joint identification board was associated with the ministry defense of australia and britain and they decided ultimately whether or not to accept the identification recommendation from the data analysis team then if they had were happy that they'd made a positive identification they then contact the commonwealth war grave commission to make sure that the soldier hadn't been buried before because sometimes and it happened in one case some soldier was buried and given an identification based on scant evidence and what they discovered was that in fact that was the wrong soldier that wasn't the soldier that they had buried in that particular grave the soldier that shouldn't be in that grave was the soldier that they just identified as the data by the data analysis team in the joint identification board so the soldier's identification would then be passed to the relevant government minister the family would be notified and the media would be informed that was the identification process the standard that they used for identification was the balance of probabilities for the army whether it was german french british but for an individual identification there had to be clear and convincing evidence that indicates that an identification is substantially more likely than not and in order to achieve that they used a variety of different techniques which i'll talk about now but just a show of hands how often did non-dna evidence lead to identification do you think so we have non-dna evidence like anthropology artifacts we didn't have dog tags but sometimes we had inscribed artifacts did that lead to that non-dna evidence did that lead to identification in roughly 10 percent of people okay one in about 10 people say that about 50 percent of people okay about six or seven people say that 90 percent of people nobody goes for 90 percent the answer is zero percent okay the first data analysis team met in 2010 there was no dna available they had made a tentative identification of only three of the 250 soldiers based on the artifactual evidence so no positive identifications were assigned based on the artifactual evidence the dna was the only thing that allowed definite identification to be made and that is one of the take-home lessons from from l without dna there's no identification we mentioned already only one dog tag was worn by soldiers at from l all personal items and id tags would have been removed by the germans to be given to the red cross so the red cross could then forward it to the families so that the family would actually have the possessions of their loved one so but it meant that there was little evidence left on or near the soldier to actually identify him the dna matching was in two groups so they they uh took the dna from the soldier and then they compared it to the dna they had from all of the families and they tried to match them up and there were two groups group one was where um the dna from the soldier matched a donor family's dna either the y or the mitochondrial or both with a very strong match probability because it was maybe quite rare dna and or it was an exact match that type of thing and the dna profile was not present in the elimination database from the people working on the site and there was no evidence of an non-paternity event adoption illegitimacy infidelity that type of thing so that was group one a strong dna match group two was not a strong dna match even because the dna profile did not match any of the current donor families there was not a match between any of the soldier's dna and any of the families or the dna matched from the soldier matched several of the donor families because it was a very very common type of dna signature and that could have been due to a partial profile where they didn't get maybe the full 17 dna markers maybe they only got about 10 or five uh it was maybe a very common y dna profile or mitochondrial profile or there were contradictory profiles perhaps because there'd been an adoption in the family and there was a mismatch there between the profiles perhaps the dna was only sufficient to identify a haplogroup and they couldn't do much more than that or there might have been a suspected non-paternity event from the family the family might have said we always thought he was adopted you know so that would have caused confusion the strongest match probabilities that were observed in the whole project was for mitochondrial dna won in 1915 in other words for this particular comparison the chances of it happening the probability of it happening just by chance is almost one in 2000 it's pretty good but 2000 is still pretty low on the y dna side the highest probability they have of it occurring just by chance was won in 3387 again using just y dna alone or mitochondrial dna dna alone is not hugely convincing for a positive identification but when you combine the two so for example if you have one in 1950 on the mitochondrial dna side and one in 3387 on the y dna side if you multiply them then you get up to one in 6.4 million now that's a positive identification you know with 99.99999 probability so it's the combination of the y dna and the mitochondrial dna that gave this project its real strength and that didn't happen in all cases because they did not get y and mitochondrial from all of these cases all of these these soldiers and then they employed Bayesian probability statistics to arrive at this overall probability that this was a positive identification and if you're interested in Bayesian probability statistics and i'm sure you could devote a lifetime to trying to understand them there's a very good presentation that was done by John Reed last year at who do you think you are in the UK which looks at the Bayesian probability statistics they used to prove that the skeleton in the car park in Leicester was rigid third and therefore he should be buried in Leicester Cathedral so that's the fancy statistic that they used there sometimes they used haplogroup information sometimes it was quite useful because if you have an unusual haplogroup then that could maybe tell you where that soldier was from so for example some people had Jewish haplogroups genetic signatures that are found primarily in the Jewish population and of course the religion of the soldiers was recorded on their service records so if the service records survived and they knew that a soldier was Jewish and you found a Jewish haplogroup among the DNA signatures of the soldiers you there's only a couple of people that it might be also um aboriginal some aboriginal soldiers were fighting in the Australian ranks Australian battalions and some of these soldiers were noted on their service forms as dark or darky or half cast terms wouldn't use today but they did use them back then also Eastern European names were recorded on the service men's records and they could be matched with Eastern European haplogroups and the same for Scandinavian but these were not reliable they were only used for supporting the identification and not for assigning the identification they were merely a pointer or a clue and that's important another point or a clue was the optimized program that they used which was a statistical program based on nearest neighbor analysis and basically what they did was they measured the height or estimated the height of all the soldiers they estimated the age of all the soldiers and then they put the age on the x-axis that's the y-axis and then the height on the x-axis and they plotted all 250 soldiers that way then they went to the service records and looked at the age and the height of all the people in the service and they were able to maybe identify just based on age and height who was the most likely candidate for a particular set of soldier remains and again the optimized program did not make identification but have offered the potential to speed up the process by using agent stature to link the remains of the buried soldiers with those missing soldiers service records again a pointer or a clue great starting point for your further investigations if you want to see the science behind the story there's a very good youtube video from lgc forensics themselves featuring dr james walker and victoria moore and in the 19th of july 2010 the last burial occurred in pheasant wood cemetery over the course of the subsequent six years more soldiers each year have been identified and those gravestones have been changed to have their name inscribed on them currently as of september 2016 thanks to michelle 150 out of the 250 soldiers have been identified 100 remain unidentified some of them are some of those who have been identified are irish howl's john berth lieutenant robert david burns private william thomas connelly private william cullen private patrick william fahey private persie heathen although i suspect it's leason private leslie william heart private william alexander jamison private william moore corporal charles william murray acting sergeant william polding ryan private daniel berger these are people with obvious irish ancestry who were fighting in the australian forces who have been identified but the search is still going on for some of the irish soldiers that died of fromel search launched for a family of donigal soldier the soldier um which the project is trying to match with his donigal relatives is believed to be joseph curran born in 1885 killed in action july the 19th first day of the battle his grandparents migrated to new south wales from crossroads in donigal their names were michael curran and dan dugham and both were born about 1837 in crossroads perfect project for a local genealogist in donigal and and that's what we need you know as a community of genealogists we can be doing a huge amount of work to try and find these people here's another one from 2010 search for relative of irish lost soldier william cadena of a company the royal dublin fusiliers fell during the battle of fromel remains are believed to be those among the 250 35-year-old private cadena's regimental number was 23042 he's married married cadena they lived at five tyron place golden bridge inch core in dublin he was one of 4777 dublin fusiliers killed on various fronts during the first world war they can be contacted at commonwealthorganiccommission.org so again trying to find his relatives here's another one from last month september 17 2016 margio leary is starting a go fund me campaign to pay for a professional genealogist in ireland to trace the remains of peter paul shannon or the relatives of peter paul shannon in northern france um they have exhausted our abuser researcher of the past two years born in ireland and came to australia in the 1890s he was born in 1883 at new ross in wexford um and he joined the australian army in 1915 in peter's case none of his siblings had children so he must look for dna commencing in ireland the formal association of australia not-for-profit organization entirely run by volunteers volunteers volunteers you'll hear me repeating quite frequently how important it is that volunteers are doing this work it's not professionals it's volunteers or it could be professional genealogists volunteering their time but peter is listed on the ancestry tree promel soldiers so if you want to see if any of your relatives are on the promel soldiers list go to that ancestry tree and if you think you can see someone there and they need some help expanding that tree please do give it so lessons from promel no dna no identification no genealogists no families to test which kind of begs the question are we adequately harnessing the power of our genealogy community to assist in identification there were 1,650 families requiring 6,600 donors to identify 250 soldiers haplogroup data and optimized data where pointers are clues and the identification process is ongoing but how is it ongoing because the they were only given a five-year remit so now it's gone back to the ministry defenses of the company countries involved and we're not entirely sure how that is going on one of the things that struck me from reading the books on promel was this paragraph here in order to establish a familial link it's essential to locate living genetic relatives from if possible both their maternal and paternal lines without living relatives it is extremely difficult to match the dna of a buried soldier to that of the family of a missing soldier as the buried soldier's dna profile without an external reference is simply an anonymous signature but now there is an external reference and you guys are the ones that created it because we have public why dna databases and these could be pointers or clues that can predict the surname of males we have why search we have family tree dna possibly the national dna database i don't know because i don't know enough about it in the uk it might be just autosomal dna but also now we have the technological advance of sampling the petro's bone with 400 times greater dna yield and the number of markers that are approved for this type of work in forensic labs as far as i understand it as increased from wi-fi 17 to wi-fi 23 and we might be getting 37 at some point of time or as a professor dan bradley was suggesting yesterday get a dna sample and do next generation sequencing on it do a big why test get those snips and then compare it with the the snips from the family's relatives so this the public databases can be a pointer or a clue and i'll show you why here's why search look how many records are in there 177 000 and 110 unique surnames family tree dna it has over 579 000 records in the database with over 400 000 unique surnames so three three point three times the number of records that are in why search here's how you use rub why search click on search for genetic matches click here to enter any sequence anonymously privately without breaching the confidentiality of the soldier who has been and his dna that's been found on the ground enter it in here into any one of these 100 marker fields and there are drop-down menus for each of the possible values that you can input i put in the first 19 markets from gleason lineage one in my gleason dna project and what i found was there were nine matches there is one there this last name is gleason you see you cannot identify any of the individuals so the privacy and confidentiality and anonymity is still preserved unknown origin unknown half the group tested with family tree dna markers compared 19 genetic distance zero so an exact match an exact match there were nine gleason matches in the first 1000 okay but not all of them were exact matches so that only gives a signal of if you like 0.9 it's not very strong but if you look just at the exact matches gleason appears in three of the 13 exact matches that gives you a single of 23 percent so this particular case gleason would be a prime candidate for the surname of the unidentified soldier do the same thing with 12 markers i enter 12 markers into this database and look what i got wheat and wheat and not only wheat and wheat and holder four out of the six exact matches were wheat in this particular case based on only 12 marker data the prime candidate for this soldier is wheat and then what they do is they go to the regimental list they see if there's a wheat in there and there is so then they go and trace that wheat and family target that family rather than all the families in the regiment and then get them tested and compare it to the soldier's dna now you can do the same with a family tree dna massie simons massie simons massie simons of 25 massie simons simons of 37 massier simons look at the regimental list is there a simons or a massie in that regiment here's one uh denman denman denman denman denman well that's a no-brainer really um 37 matches there's a variety of names there i had to go up to 67 to get two gleason's on my blockum and go up to 111 to get a little in the gleason gleason's most likely candidate but i've had to increase the marker level to 111 so it doesn't work in all cases at low marker levels how often does a y dna test predicts the serenade around about 10 to 15 percent based on um data that i collected in 2014 at who do you think you are in london 25 percent of men who do a y dna 37 tests have no matches 50 percent of 1 to 10 matches 25 percent have about more than 10 matches and about 10 to 15 percent of these 130 that i looked at had a clear signal of their own surname in the results and that is likely to increase in time as more and more people test so future considerations an unknown soldier is found the regiment has identified all families of regiments missing soldiers are traced and the dna is tested very very costly instead what you can do is narrow down by an assessment for certain candidates check the serenade candidate against the regimental list identify potential candidate soldiers and target the tracing and testing of that particular soldier's relatives hugely reduced costs and that is what will sell the project to the government so i need to get them to listen uh likelihood of being found 30 bodies are recovered out of 338 thousand that are known to be missing the chances of your relative being found is approximately one in 100 000 per year remote the likelihood of being identified if we take a conservative estimate of about 10 percent using the dna is one in a million per year one in 100 000 per 10 years one in 10 000 over the next 100 years if there's still viable dna to test at that stage so it's remote but even one identification means something to somebody uh what can you do to commemorate create a gene logical memorial digital dna memorial or strengthen the online databases document your own genealogy of your fallen relative put it up online with a paper trail for later independent verification identify potential living descendants for dna testing and leave a digital dna memorial if you already have done a dna test including a link to his genealogy the dna data is available and include your contacts details and you can do that either on lives of the first world war website or every man remembered website and here's one that i left for um my second cousin twice removed michael spiram who died in france we know where he's buried but i leave it as an example michael spiram was my second cousin twice removed with about 10 children his family tree is online at ancestry and there's the link and that's where he's buried and various relatives of michael spiram have undergone dna testing michael's dna is shared by the following people y dna hit number eight q h y d on y search 209 715 on family tree dna his second cousin twice once removed mitochondrial dna no one tested but cousins are available orders on the dna here's 221175 on family tree dna his potential is paternal first cousin so that's the kind of digital dna memorial that you can leave to encourage people to actually start leaving dna profiles for their fallen relatives um you can strengthen the online databases by uploading your y dna to y search uploading your mitochondrial dna to mito search uploading your autosomal dna to get that and then putting the kit numbers on your digital dna memorial i have a world war one missing action dna legacy project on family tree dna you're more than welcome to join should you so wish and it's really just to leave there's just a memorial really um using because we are genetic genealogists but the whole purpose of this process is to try and turn this type of gravestone a soldier known onto god into this type of gravestone which actually has the soldier's name and giving soldiers the dignity of having identification in death so thank you very much i can see people queuing up outside so um we probably don't have any time for questions because it is now 10 past four so if you want to talk to me afterwards i will be uh around downstairs or tomorrow morning before the lectures so thanks very much for your time yeah sure sure my interest in this is how a great uncle who died and simply wants to about to leave our research this whole war history and everything about me is


Welcome everyone to another OpenShift Commons briefing. And today, very excited. We have Miguel here. He has been working on and with the engineering teams on these migration tool kits. And we're so excited for this migration tool kit for virtualization. It's definitely been long awaited. Miguel, do you want to introduce yourself and talk to us about migration? Sure. Well, my name is Miguel Perez-Colino. I'm a product manager. I'm the product manager for Migration to OK for Virtualization. And I'm in the modernization and migration team in Red Hat. And, well, I'm taking care of this tool that has reached the beta stage just last week. And I was like, OK, I have to go to OpenShift Commons to show it. So we are going? OK. So first things first. OpenShift containers and VMs. So the migration tool kit for virtualization is intended to move virtual machines from initially from VMware to OpenShift. And then in the future, we'll add more sources and we'll keep the same target. And the target is OpenShift virtualization. So what is this about? So this is saying containers are not virtual machines. And another saying that goes containers are Linux. And Linux is containers. So the containers is a way to isolate process. It's like a super-isolated process using kernel-limit spaces, C-groups and SE Linux in behind-the-price Linux to be able to isolate those processes very, very well. And, well, virtual machines require guest OS and an hypervisor running. But the thing is that in Linux, virtual machine is also a process. And we could encapsulate that process. And the thing is that the operating system, Linux, has the kernel of virtual machine, which is like an engine to be able to run virtual machines, which is used like in almost every public cloud for virtualization purposes. And the thing is like, well, this is very performant. Try to think what 1% increase in performance would mean to a public cloud. So try to understand that, I mean, this is like a super, super good engine for virtual machines. And it's included in Linux. It's included in behind-the-price Linux and Core OS that they use in same kernel with same KVM. So we could leverage that and all the experience we have in in Rehab Virtualization and OpenStack to be able to build virtual machine capability on OpenShift. So this is how we get to OpenShift Virtualization. What is OpenShift Virtualization? Well, we have adapted Kubernetes and OpenShift to be able to run virtual machines. So we created the project QBird two years ago, and no, three years ago, if I recall correctly, and QBird matured and became pretty solid. And then one year ago in April 2020, we released OpenShift Virtualization and now it's available to run virtual machines in OpenShift next to your containers. With all the benefits that brings being able to run something on Kubernetes, like this declarative way of deploying infrastructure, all the operational benefits with Prometheus to gather metrics and all those benefits that you know and love from OpenShift plus, the interfaces to network and storage that OpenShift has been developed for so long. So that's good, but what is this for? You know, it's all about modernization and migration. You know, customers and users, worldwide and developers, they all want to become more modern because it brings a lot of benefits. So when development teams start using containers, they become more agile, faster, they have a lower time to market, they release more frequently, in case there's an incidence, their time to restore is reduced. There are these metrics that we all know that get improved when you start working in a cloud native way. So what if we could move these workloads that would make sense to have next to containers into OpenShift and have them next to the containers so they could behave more like you are in a container and then over time, modernize them. So it's a lower friction way to bring those VMs into a container-like world and have one converge infrastructure for those critical workloads that we're going to manage and then be able to do all that low modernization process step by step during the time. So what are we thinking? What if we could automatically convert VMware images to KVME images on OpenShift? Well, that would lower the cost of migrating the workloads, okay? So that's a direct benefit of this. So what would this look like? So let's say we have these web logics with Apache Frontends and a database running on VMware. We could move them to virtual machines and then modernize, for example, the Apaches. They are pretty easy and then put those Apaches in containers or even change it for Nginx and then be able to, okay, all those Frontends make them, drag them to containers. Then we could move to, for example, take some application from WebLogic to Jboss or keep them in WebLogic on containers. That's something you could also do on OpenShift running WebLogic in containers, same as WebAsphere, Jboss. But in this case, let's think, okay, we're going to move this application to Jboss. Let's modernize the application. Let's make it a leaner and more standards-oriented so it can run on Jboss. So we are modernizing that and then we could end up modernizing all the applications and even moving the database into containers at some point in time. So this makes a very easy iterative approach to modernization. It's a really good way for you to be able to, as I say, first shift the workloads into virtual machines and then do the modernization at your own pace. How do we approach this? Well, you have the workloads and there are some strategic workloads and some not strategic workloads that you could analyze with assess with Pathfinder and analyze with migration toolkit for applications. And well, what can you do? You could reply from them as VMs, you know? So you just move them whenever they are VMs, as VMs, whenever they are containers as containers, you could refactor them and repackage them as containers. So you modernize the application, you could repurchase if it's a third-party application and then put them in OpenShift project. So you test them in OpenShift, they're good, they're not good, we fix them, we test it, they're good, once they are good, you deploy to production in OpenShift and then you're modernizing. What if we want to further enhance? Well, we could go to the refactor loop again and improve, improve, improve. So this is, for example, a pattern that we have seen with large monoliths that you split them and you modernize them, modernize them, modernize them. And then modernization is complete. What do you do with the non-strategic workloads? Well, retire, rehost, retain. So some of them you could retire them, some of them you could rehost them, some of them you could retain. The retire has like a second fold, like for example, if you're running your own email process, probably you want to move it as software as a service. So there are several options for the non-strategic workloads that could be provided as a service that you could consider working on. So we are working mostly on the replatform, refactor, and report this, focused on replatform and refactor. For migration token for visualization, it's fully replatformed to move VMs from VMware to OpenShift revitalization. What are the benefits and the operating costs? Well, you see there are more operating costs in a rehost to retain because you have to keep your current infrastructure. If you retire, it's pretty easy, but you lose some services. And then when you do replatform, there's more business benefit. And when you do replatform, there are even more business benefits that you could obtain by doing this one. So what do we do in my team? Well, we have tools for these cases. In rehost, we have a tool called MTC Migration Token for Containers that the upstream project is called Crane. Then for the replatform, we could move containers using move to queue that will bring the containers running on Cloud Foundry to OpenShift and Forklift, which is the upstream for the migration token for revitalization to move VMs into OpenShift revitalization as VMs. And then the refactor, you have the Pathfinder and Windup projects that will result into the migration token for applications. These are the migration toolkits. And then you will be able to analyze and assess the applications to be able to first with the assessment, be able to choose which applications to work first. And then with the analysis tool, be able to start transforming them to put them in containers. How about the tool? Any questions so far? Is there anything on chat? And not yet, this is awesome. Keep going, have lots of... Okay, I keep going. So what I said, we have these projects in the upstream. This upstream is conveyor.io project. I really suggest you to visit it. If you go to github.com slash conveyor, you will find all the projects that we put in there. Some of them were still not migrated. This is like pretty fresh, pretty new. So with the desert to go there, there are like mailing lists, there are forums, and we even have some meetups to show, like the inner links and all the technical stuff on the projects and be able to help everybody to join and be able to contribute. So you see this project crane, porcliffe and tackle. Crane, then we have the downstream, which is the tool that we provide the migration token for containers to migrate from OpenShift 3 to 4 and also from 4 to 4. So this case that you have a cluster that is getting full and you want to move some applications outside of it and your pipelines are not that easy to repurpose, then you could use MTC easily to move those containers and their persistent volumes easily from one cluster to another. Then you have tackle, which becomes the migration token for applications. As I said, to assess and analyze applications. So you could analyze the applications, the applications with this tool, and it will tell you, okay, you have these things in the application, like for example, you're using a proprietary logger or you have Windows specific paths or you're using a proprietary class from the Oracle JDK and you want to move to OpenJDK. Well, you can use MTA and the migration token for applications for that. And what I'm going to talk about is the migration token for visualization. So what does it do? It's prepared to do migration and scale of virtual machines to open-safe visualization. So we have built tools before to do migration and scale and we have used those tools before to do migration and scale. So thousands of VMs have been migrated. And now we are building this tool with all the lessons learned from the previous tools that we've built, but with the target for, that the target is going to be open-safe visualization. So you can mass migrate virtual machines to open-safe visualization. Where are we now? Well, the beta is out. So it's very easy for you if you are an open-safe to be able to install it and I will demo it in some minutes. About the architecture, everything open-safe, everything container native, everything in containers. So we are using all the natives that we can. You see that we have a source which in this case is VMware BSphere. And during this year, we'll be adding revitalization and open-stack sources. So just in case you want to move VMs from these sources to open-safe visualization. We have an inventory service that is going to gather all the information from VMware BSphere. And we have a validation service that is going to check, okay, how is this VM configured? And it's going to run checks there. And if something is not right, it will raise it and will say, hey, I found these that could be an inconvenience to migrate this VM into open-safe visualization. So you do not start a migration that could fail, okay? So maybe you need to check things like road device mappings that are attached to the VM and that you want to keep as roadways mappings or that two VMs are sharing the disk and you don't want to end up with two VMs with two disks but two VMs with one single disk that is attached to both of them. These kind of things are the ones that are checked before. So the migration is run as smoothly as possible. So we are adding more and more rules to the validation service to ensure that when you migrate a VM, it's going to be as successful as possible. Then we have the user interface, of course, built with pattern fly for. I love the pattern fly project. It makes our interfaces look so nicely. And the thing is that we try to make it as simple and nice as possible to be able to be used, even if it's powerful, try to make it really simple and nice to use. What do we have in there? We have mappings to be able to map resources from source to target. We have migration plans to be able to say, okay, which VMs are going to be migrated in the same batch. And then we have the migration run to execute the migration. And then, of course, there's the controller and then there's the capability to import VMs in offensive utilization that we leverage to be able to move it. And then, of course, the import operator that is handled by it. So this is the architecture. If you want to have another session with more technical details, we can invite my friend Fabien Dupont and we could have another session to talk about the internals. What else? Okay, providers. First thing, we need to connect source and target. So we have a provider that is the sources, right now, VMware vSphere.  So you have to connect the tool to the provider, which would be VMware vSphere provided credentials and also to the target. When you deploy a migration token for visualization, the OpenShift instance in which you deploy it, it gets configured automatically as a target. So very easy. If you want to do a simple migration, it's going to be very straightforward for you. So we use the sources, the destination. So we have, okay, this is from where to where. And now how? How do we change what is already there? So normally, what you have in the source is a set of configured networks. They normally attach to VLANs, depending on how you configure it, but it's pretty common that you have a certain set of VLANs that you attach to your virtualization network that one of them is, for example, to access a storage. Another one is for administration. Another one is internal. Another one is the DMC to be able to publish services outside of your environment. So these are the network mappings, the network configuration that you have in your source, and you have to create the mappings. Now you have to do it. So what you do is that you deploy your new environment, your OpenShift environment, and you configure these networks in OpenShift. So once you have configured the networks, if you could extend the VLANs, it will be a lot easier. Then it's very simple. You just take one VM from source to target and it will be connected to exactly the same network it was in the source. If not, of course, you can always change the addressing, but I mean, if you can extend the networking configuration, it will be the easiest way to do it. So with this, we can map the networks in the source to the networks in the target and be able to make them equivalent. So whenever you choose a VM that has an interface connected to a network in the source, the VM that we will create in the target will have an interface connected to the same network, well, the equivalent network in the target. If you have configured properly, it will be exactly the same network. So this is a very simple way not to have to be changing everything every time you move a VM. This is intended for mass migration. With the storage, we do something very similar. You have your storage configuration with your data stores in your VMware environment and you have your storage configuration with your storage classes in opens here. So it's very important to select the storage in the source similar to the storage in the target. So the storage in the source, sometimes you're using, I don't know, NFS, ISCASI, sometimes even fiber channel depending on the IU that you're going to require. And then in the target, you have something like CIF, for example, we have another ISCASI provider or an NFS provider that you have configured as a storage class. So you can allocate persistent volumes automatically. So do map A to B, this data store is going to be mapped to this storage class in the target. So whenever you start migrating, a disk is going to be created in the target which is due to the mapping equivalent to the source. This way we map source and target and we make it very easy to perform a mass migration. Any questions so far? Okay, I keep going, please interrupt me if there's any question coming in the chat or if you want to ask anything. So next step, so we have the maps, we create the migration plan. This is where we select the VMs. Of course, we have all the ways to filter the VMs to make it easy to select the VMs that we want. In many customers that I've visited and met and work with, they have their own name in the structure. So filtering by VM name is usually very common, very easy but if you want to choose also the data center or filter by cluster is very easy to filter the VMs and get a set of VMs that you want to migrate together.  Of course it will check that the network in the VM selected is in the network mappings and it will not, it will warn you. You can choose the storage mapping, same thing to be able to do that. You will review the plan and you will be able to execute on it. Of course, we want to add not in this version but in the next one, migration automation which is sometimes when you want to do a migration before doing the migration, you want to deactivate monitoring for that VM or if the VM is part of a cluster that is redirected from a load balancer to detach the VM from the load balancer or make changes in the DNS. So you could automate all the process before the migration and then after the migration re-engage with monitoring we attach the VM to the load balancer or perform any changes that you would like to do it. So this way we ensure that all the tasks that you want to do during the migration could be done. It's not going to be ready for the tutorial but it's going to come in the next version. And then of course we'll be able to monitor the migration progress, cancel who doesn't like a progress bar, right? So we already include a progress bar of way to monitor how things are going. And then a bit more about roadmaps where we stand. As I said, we released last week the beta with capabilities to do mass migration and we are preparing in May to launch the GA with warm migration. This is pretty interesting because the data in the VM will be copied without powering down the VM. And then when you want to perform the last step of the migration, do something on the VM, copy the Delta and then power up the VM in the target to reduce the time required for the migration. We normally for this kind of migration there's an intervention window required and first we want the intervention window to be the shortest possible and second we want to make the most of that intervention window which normally is not at regular times. So we are looking forward to helping our friends our assessments out there when they're doing their migrations so they could make the most of their migration windows. Also the pre-migration checks to be able to check the VMs before doing migrations to detect potential compatibility issues before migrating. What else? Well, if you have any questions, comments, contributions, any suggestions, anything you want to tell us. I mean, we have this email migrate at redhat.com. Please use it. Please send us your questions. Please send us your suggestions. And if you have any doubt, of course, share it with us and let us know because the whole team is here listening to help you. So we have this email for you to be able to contact us. And that would be it. I mean, I'm willing to show it to you if I may. May I? Of course. We do have a couple of questions if you want to take a... Oh, great. Nice. Tell me. So let's go ahead and get some questions answered before you dive into the demo. I'm really excited to see the demo though. All right, so vCenter version, 6X and above, do you support? VCenter, 6X and above? Yes, we support. What we test is 6.5 and above. And we normally... What we use underneath is VDDK from VMware. So we behave like any other backup software. So what we do is we connect just like any other backup software using VMware certified mechanism to do BAPCAP, which is using BDDK. And we are using this BDDK to extract the data. And the current supported BDDK, it's only supported for 6.5. However, we know that this is a backwards compatible and that you could use it to access any other previous version of VMware. So you could run it, but we know... I mean, we say this is what we test. And if you want to use it for something else, of course you can do it, but just letting people know what we are testing. And if they have any issues, they contact you at migrateatredhat.com or... Yes. Also the Conveyor.io community, would that be... Yes, these are the places to contact us. You can go to the conveyor.io community and open your... I was trying to open it, but it's not working. Right now, seems that my DNS is not working well. So yeah, you can go to Conveyor and just join the Slack channels that we have on the Kubernetes environment. So you could go to slack.k8s.io.com.io. And in that Slack channel, I mean, there are channels that say MTV Migration and Togepropitalization. You can join it and you can, of course, tell us there how is it going and propose your suggestions. So any of these channels is good to contact us. Nice. During your demo, I'll pull up the link to that Slack. Also, are you able to share storage between your target VMs that are running in Kubevert? Are you able to share storage between the target VMs running on Kubevert? Okay, so this is more an opposite virtualization question. So I'm not completely up to date on the status of shared storage of opposite virtualization, so I don't want to say something that is wrong. But I mean, you could check in the documentation of opposite virtualization, the official documentation, and it will stay there. So... Or ask for that Slack channel. Right? Yeah. In the Slack channel. I'll say, let's see. I'm assuming this only works for supported VM infrastructures. Are there any limits from where the VMs can come from? Can I import from multiple types of infrastructure? For example, REV or Azure at the same time? So we built a provider for VMware to be able to import from VMware and we are working in building another provider for virtualization. And by the end of the year, we want to work on adding another provider. But of course, if somebody wants to try to build his or her own provider for Azure, Amazon or whatever, and they want to share it in the community, I mean, we'll be very, very happy to lend a hand there and to help with the provider. And then once it is ready, include it in the downstream version of the migration token for virtualization. Nice, thank you. Two more questions and then we'll get to your demo and then even more questions after that. All right, what about VMware tools after migration? With all the recommendations, do you recommend cleanup of VMs prior to migration? Like cleaning up your temp files, downloads, old programs, et cetera? We are, in this case, we are standing on the shoulder of giants. Well, I don't know if it's giants, but we are standing on a lot of proven technology before. So there's a tool that comes with Rahander-Price Linux that is called V2V, virtual to virtual. This tool was created to extract VMs from VMware and put them into QMU, or for example, Rahander-Price Linux or any other QMU supported environment. So it could be used to import into REF, it could be used to import into OpenStack. And we are leveraging it to import into OpenStack virtualization. So one of the things that V2V does is that it streams the disk and while streaming the disk, it removes all the VMware drivers and tools. So whenever it, and adds the drivers necessary for the target, like the virtual drivers. So whenever the VM arrives at the target, it will be booted and it will be booted correctly because it has the right drivers. Nice, thank you. I'm going to go test out that tool myself later. I mean, that's the common in version. If you want to have the easy to use version, you could go for MTV because it's going to use that underneath. Are there any benefits of using MTV over the VM import wizard available today when wanting to import just a single VM? Yeah, one of the things we are planning to do and I think it's going to be done, I'm pretty sure that that's going to be on schedule is that this migration token for virtualization is going to supersede the import tool. So the import tool is just for you to test one VM to import it and there's code in the import tool that we are leveraging for the migration token for virtualization. The benefit is that you can plan this. You can plan it with a list of VMs. The other benefits that you're going to, whenever it goes GA, you're going to be able to check that the VM doesn't have anything that will make it, that will render it as unbootable or unable to be migrated before you migrate. So we're going to check that. And then the third benefit that we are working on delivering for GA in May is that you will be able to do a pre-copy before doing the migration. So whenever you do the migration, you only have to copy the delta and reduce the amount of time necessary to do that migration. So these are the benefits that MTV is bringing versus the tool that comes with OpenShift to import one single VM. Awesome, thank you.  Cool. So OpenShift, OpenShift Virtualization, right? So you have your OpenShift instance and it's OpenShift Virtualization supported on bare metal nodes. So you will need some bare metal nodes to have it supported, although you could enable nested virtualization like I do here. So things are going to go a bit slowly because we're going to be using nested virtualization but I expect this to work properly. So this is our lab environment. This is OpenShift 4.7, as you can see here. This is the supported version. I can go to the installed operators and choose all projects. And I will see that I'll have OpenShift Virtualization operator installed and configured. So you have this OpenShift Virtualization version 260 is the one we are testing on. So if you want to run on a tested environment, then you should run migration token for virtualization on top of OpenShift Virtualization 260. So what do you need to do? You can install migration token for virtualization, the operator, and then you will be able to use it. So how do you use it? Well, I just can go this, when you start it, you get like a project created, OpenShift-RHMTB. And if you go to networking for this project and you check on routes, there's a published route, which is the interface to the migration token for virtualization, which I have it open here. So I've let it load. This is the interface, okay? So it's pretty straightforward. Once I've completed the migration, I could do a quick demo on how to install it. So I could go here and get started. This is like just deployed, okay? So first thing I need to log in. I need to get the credentials. You have to log in as a cluster administrator. So give me a second that I'm going to gather my credentials, please. Okay. Yeah, I'm gathering my credentials. Give me a second, please, please, please. Log in, I'm logging in and I'm going to share my screen again. So sharing my screen in three, two, one. So I log in here. Is logging in? Okay, I'm in Spain and the cluster is in Boston. Expect some delays while running this demo. But, I mean, I've run it a couple of times and it worked well. So I can get started. I see the providers. This is the provider where the operator was installed and instantiated and it has found seven storage classes and it's completely ready. So I could add the provider now and I could select VMware and just provide a name to it, vcenter and then provide a host name, so our vcenter host name, provide a username, so administrator at vSphere local, then the password, I type the password, then the fingerprint. This is to ensure that we're connecting to the right VMware provider and we're not connecting to something else. So once we do that, it's going to connect to VMware. I could go to provide this VMware. It's going to check. If everything's okay, it's gathering the data. You see two clusters here, two hosts, 56 p.m., 13 networks, four data stores and now it's ready. So we have the provider ready, the target provider, sorry, the source provider and we have the target provider, obviously virtualization, both of them ready. So now we could create the mappings. I could go and create network mapping. So I create the mapping and I name it, you know, name it mapping network because I'm very original. So I choose mapping network. I choose the provider, the source and the target and I have to choose the network equivalences. So I go on the source network and I choose the VM network and then on the target, I select the port network and this is going to be my mapping. All my VMs are going to be attached to the VM network and this is going to be reattached afterwards to the port network, okay? So I can just create the mapping, okay? And this is the mapping that I have created. It's completely available for as many migration plans as I want to use. Then I could go to storage and create a mapping, same thing. And then I create the mapping storage mapping, select the provider, be center, select the target post and then I know that my VM is running on the NFS data store, but I mean, I could map the other ones and I want to use the storage cluster self-RPD because I'm using offensive container storage here. So it's properly distributed, it's over defined and it works really well. So I could create this map and I have the two maps ready. Now let's migrate. I go to migration plans. I create a migration plan and I give it a name. So I'm going to call it MTV plan and description MTV. I select, I select the source provider, be center. I select the target provider, this host and I love this. I mean, you could select a namespace and all the ones that are created or I could type one MTV migrate. Okay, and if I click here it will create for me this namespace. Okay, good, next. Then I'm going to filter the VMs. I'm going to choose this cluster which my VMs are running. And then I go into click next and then it's getting all the list of VMs. So there's a lot of people working here. I'm going to filter the VMs by my name and there we have. We have this relate VM that is running that I'm going to migrate. I chose a small VM to make this migration quick so we could see it happening. So I select this VM. I could select like 20 VMs if I wanted to. No problem with that or 30 or 100. And then I choose the network mapping. Select this one. Next, I choose the storage mapping. You see, I could create a new storage mapping in case I was missing it here. Next, and then I review the result. These are the results. I'm going to migrate only one VM. I could migrate 100 but I'm going to migrate only one. And these are the mappings and this is the plan and I can click finish. And then everything's ready to be migrated, right? So I could click start and the migration will begin. One of the things we are planning to add is to be able to schedule this process so you could say, okay, let's run it at three o'clock in the morning. Now that I've been running it like 20 times I'm completely sure that is running well. So let's get it running. This is the progress bar of the number of the VMs migrated. So in this case it's only one so it's going to go from this to green. And but we could check here if we go to the details that right now is in the transfer disk phase and it's copying the first gigabyte of data out of nine. So it's going to be copying and streaming the data and then it will convert the image to Kupferd doing all these transformations about the drivers that I mentioned and cleaning up tools. So when we're completed it will be totally done. So this is now running. I could go to up and shift. I could go to overview, projects and then select the project that I just typed MTV Migrate and this is the project that has been created for me. It wasn't here before. I could click on details, workloads and then a VM will be created here in the workloads and I will be able to check on it. Let's give it a couple of seconds. Let's see how is this going? The transfer and disks. But it seems that this, you see the VMs already, the instance is already created and now a disk is going to be attached and a network is going to be attached and this VM is going to complete the migration that will be running. So this is the demo so far. We have to wait for it to complete. It normally takes around eight minutes. So if you want, you could shoot more questions. Wang, I know I have a lot of questions but wanted to wait until the end. The demo itself, yeah, it's that simple. I guess I was like... It's like super, super simple. I mean, our friends in user experience and design are working with us and are making things like super easy, super easy to understand and very well located and then the engineering team is focusing on making this as robust as possible. So we end up with these tools as you see like very simple and very reliable. So amazing demo. I mean, I just, I wanted it to keep going but so one thing that I was wondering is at the beginning you mentioned analyzing your applications using the toolkit, right? The migration toolkit for applications and then using the MTV. So how did those line up together? How does your planning go? That's a great question. I don't know who mentioned it but I love it. Look, we have in here it's called Forklift. This is, let's say that this is MTV and in here we have wind up, this is currently MTA. So these are the two tools that we have available. So in case you want to read platform and bring virtual machines to Kubernetes, you could use MTV. And let's say, okay, I'm moving 20 VMs with JBoss Enterprise Application Platform to containers and I want to turn those applications into something, apply a stronger pattern and be able to turn it into microservices or I have them running in WebAsere or Tomcat and I want to put them in containers. So there are a set of paths that MTA covers, the migration toolkit for applications and what MTA is going to do is analyze the application at the application level. But what you can do is that you take the VM as it is in VMware and bring it to OpenShift. And then you already have older developers walking in OpenShift with an environment built for developers that developers enjoy and understand. You can manage it in a way which you could manage all your environment for cloud native applications but with virtual machines to make the transition even smoother. So once the VMs with your WebLogic, let's say they are running on your OpenShift virtualization, you will be able to take those applications and analyze them. And the thing is that what MTA does is pretty simple, and I can run it for you, I have it here. So you just have to give it an application and it will analyze it and it will tell you what do you need to change in the application to do the migration. So these are the two ways you could improve or modernize your current status of your application portfolio with OpenShift and with the tools that we provide with MTA and with MTV. And there are two different paths. One of them is, as I say, focus on applications, on improving the application and bringing it into a container environment to a cloud native world as fast as possible, which is not normally a fast and easy way to do it. And the other one is just lifting and shifting the VMs to half all the applications in the environment that your developers want to use. So for that, I mean, you could go to red.htslashMTA and download it. This is version 5.1 so far. So you just download the zip file and zip it, run the script as I just did, and then you will be able to run the migration type of applications, analyze your applications, and then this is what you will see. And you're getting two demos at the price of one. So this is an application that I analyzed that is completely ready to run on JvoCAP, whereas this other one has some WebLogic proprietary artifacts that need to be changed. I could dig down into this application, check the issues and be able to check it. Look, I'm using the WebLogic proprietary logger and you need to change it. So these are the two paths that you could follow. And normally you follow first migrating the VMs then migrating the applications, although sometimes it makes more sense to do the application migration directly depending on the status. But for that, I mean, you could count on our consulting team that they're always there to be able to do a discovery session and help the customers decide on what do they want to do, what is the best path and how to get there. Did I reply to the question? Yes, yes, that was great. And then we don't always want to say, hey, you have to use consulting, right? No, no, I mean, there are a lot of partners helping our customers doing these migrations too. And these partners are, as I say, they are like very skilled because they have been doing it for like a lot of time. And I mean, it's a matter of the customer choosing how do they want to do this modernization and how to get to this journey to the open hybrid cloud to provide a better service for their own clients and to be able sometimes to expand their addressable market and be able to grow faster. So yeah, if we could help our customers in that way, we're always willing to do it. Thanks. I wanted to point out a great comment in the chat. A staggered from a little bit earlier, a staggered schedule would be nice too if I'm migrating 100 VMs. Yeah, that's... Yeah, my colleague Fabien, who is the engineer manager, is going to love hearing this because he's already thinking about how to establish some throttling and how to make this a scale to be able to move like a large number of VMs, we're thinking like hundreds. So yes, it's something that is in our minds, but right now we have just released the beta and we keep adding features and that is one of the things that we keep in our minds to do for the future versions of the Migration Token for Vitalization. Thanks for the comment, by the way. And then there's, are there any issues if the VMware environment is using Vvolves? Vvolves. Yeah, the Vvolves so far, what we have tested, if they behave, there are like some corner cases there in which we find some issues when obtaining the data from the Vvolves, but it's very unlikely to happen. Because again, the way we are extracting the data from the VM is the same way a backup solution would do. And VMware wants their backup vendors to work well with their Vvolves. So normally if there's an issue structing data with a very weird corner case or is because there's something wrong with the implementation but of the Vvolves, because we are using the toolkit that the VMware provides to be able to extract the data from VMware. So we should be safe. So I know, I mean, myself, I feel that panic if I hear it should be safe, right? Especially when you're talking about data. So... Yeah, yeah, yeah. No, no, no, no, you're right. I mean, that's why we follow the safest path. But for this, I behave like an engineer. You know, if I haven't tested like 1 million times I'm not going to say it's safe. But I mean, it's as reliable as any other backup tool. Which is... So I was gonna ask how do, if there is an issue do you see the error right away? How are you notified of that corner case? We are getting the, I mean, if doing the migration we get an error, we'll see it here directly in the interface. We are putting all that we can to be able to make the error messages as clear and explanatory as possible. That is key to be able to perform migration because one single migration VM that is not migrated will be a problem. And then what we're doing is that right now we're releasing the beta as early as possible. So people could start trying it and giving us feedback on these corner cases. And the second part is that, again, we're working on having the log or the error messages as clear as possible and to be able to gather all the logs together. So this is the direction we are heading. Of course, as I said, we are choosing the safest path. So right now this beta, what it does is that it powers down the VM and then it starts copying the data with the VM power down. So the VM is in a consistent state and then it powers out the VM in the target but it doesn't remove the VM in the source. So if there is any corner case that we forgot about that we couldn't find or that we are not aware of, you know, you can always choose down the VM that you have this migrated and power on the VM that is on the source. These ones are kept and normally when we've done migration with customers, the initial migrations during the pilot phase before we scale, we keep these VMs and we do like a batch of tests to the migrated VMs to ensure that they are running perfectly. And then when those tests are completed and are verified, then it's when we delete the source VMs. So normally there's a period of time in which you keep the source VM as a way to be able to rollback just in case something didn't work as performed. But so far our experience is that whenever the VM gets completed and then it's completed, unless there's a misconfiguration of networking, then it works as in the source and it works properly. So no concern about that. Dan had a follow-up question, but I think you already answered it, but I'll say it anyway. So what if the source VM has snapshots? Will that foobar the migration? So if you're already bringing down the whole VM, are you worried about the snapshots? This is something you got me. I'm not completely sure. The previous behavior is that we collapsed the snapshots. So we didn't have any issue with the snapshots. I mean, VMware is telling all the customers, look, don't use the snapshots for backup. So if you have a snapshot, they should be able to be collapsed. We are working on not having to collapse the snapshots, but right now I don't know the status of this. So I may need to follow-up. Yes. Yeah, just a quick note on that. We are not deleting snapshots. So actually it was in IMS 1.1 and IMS 1.2, we value daily that it works without removing snapshots at all. So we kept on that line and the snapshots are not a problem. From the VMware point of view, if the VM is down, we're actually, it's going to use the current state of the VM as a base to do the transfer. So whatever snapshots you have, you keep them. We're not removing them. And the current state is the image that we are moving. So even if you want to rollback, you keep your previous snapshots. So if you use them as point in time for other rollbacks, you can continue to rollback even further in the past. For one migration, we are creating snapshots for change block tracking, but normally they shouldn't affect normal snapshots. It's something that we need to verify with real virtual machines that we kind of try to break and see how it happens. But that's something in our test plan for the one migration. Ladies and gentlemen, let me introduce you to Fabien Dupont, our engineering manager for the migration to careful visualization. Thanks a lot Fabien for coming to the rescue. And if you want to stop sharing your screen, Miguel, then you can. Sure, I mean, it's going to take a bit more, some more minutes. So yes, I'm going to stop sharing the screen. Because I'm really excited that you jumped on Fabien too. Thanks. I was listening so far, you did very well. Thanks. We have a couple more questions. I saw that the distributed switch port groups during migrations, those networks are not an issue, correct? Distributed switch port groups. Dan, do you want to ask live or if you're... They are not an issue. They are considered like any port group or traditional network. The main difference in our opinion between a normal network and a distributed v-switch or distributed port group is that with a distributed port group, you don't have to configure it on every ESX side. So it might be that some of the networks and the source don't exist on all the ESX sides when you have a traditional or legacy network. But if you're using distributed v-switches, it's going to be automatically configured for you. But from our point of view, it's just another network on which you can have VLAN tagging, empty parameters or whatever network configuration VMware has. So we already take care of them. Nice, that answered his question. Also, this is a great question too. I was wondering this as well. So Mike asks, is the source VM still alive after the migration? Well, it's still alive, but sleeping. So we shut the VM down, but the VM is not removed as we can explain. We keep it as a backup plan. So if anything is wrong on the destination, you can still rollback, your VM is there and it's an easy rollback and really fast. That's why we keep it, we keep them. So are there any, have you run into issues as you're building out the tool with network contention or has anything accidentally stayed up and now you're worried about two things live? No issues? No major issues. One thing we've noticed is that we've seen sometimes Windows machine not really appreciating to be migrated, but usually it, well, trying the same VM from a different vCenter worked. Like it's, we considered more than being an environment issue in the test labs we have rather than a VM or conversion issue on 32e. From a network convention point of view, of course, the faster the network is, the better to reduce the downtime, mainly. It's really a question of downtime. We are doing our test in PSI and it's not super fast environment because we are sharing the network with many other projects. So sometimes it's quite slow and well, the migration goes to the end. It works. It's just that you have to be patient. So yeah, we really advise to have a network benchmark before you start doing mass migration to have a clear assessment of what the platform can support. You also don't want to crash the network and have an impact on running VMs or on backups because they are likely to use the same storage backend too. So if we have two processes reading the same disk at the same time, going to like probably slow down the backup, which is not a good idea. If you want to keep your, if you need to rollback. So general recommendations similar to doing backups, don't do it over your production network, right? Yeah. That's just a reminder. All right, so we have a couple of minutes, three minutes left and there are questions around OpenStack and Rev. So can the source be Rev or OpenStack and is there a supported migration path? It will be. We're walking on it. So let's say that for third quarter of this year, we, if everything goes beautiful and wonderful, we'll be able to have Rev as a source and then by the end of the year, we want to have OpenStack. So it's in the plan. It's, we already considering it. Other providers like Hyper-V or Nutanix are not in the plan right now. However, if somebody wants to contribute that, we are more than willing to listen to them and to help them ramp up to be able to build it. So that's more or less the roadmap, yeah. Or if you have a customer with some budget for engineering. Yeah, also, which may happen. So again, go to conveyor.io and that's conveyor, K-O-N-V-E-Y-O-R.io. I hope I spelled that right. Now, I'm going to show you the website for a second if I may. Perfect, yes, please. We just updated it recently. So we can have all the information here, all the projects we host, containers we host, virtual machines, we platform, measure software delivery performance, refactor applications to Kubernetes and meetups that we do also that with content on real-world example, in many cases, in which, well, we invite people to the community that are, especially in the field, working with customers that could provide kids and feedback on how to perform a good migration and what to avoid and what are the best practices, yeah. All of the meetups that I've been to so far have been great.  So definitely recommend, you know, going to those virtual meetups right now. Yeah, in MTV, we are in beta, so we're going to start rolling and whenever we have these run with customers for large migrations, I mean, I'm going to invite whoever is involved to be able to share the experience. Well, thank you and we're at time and thank you again. That was a really great presentation, great Q&A and definitely we'll have you back for a follow-on. Happy to be here and thanks to you for inviting us. Fabienne for saving me and Chris for taking care of the backend of this meeting. Yes, thank you, Chris. And if you want to see us out for everybody else that has joined us on BlueJeans, Chris is seeing us out on OpenShift TV on the live stream and thank you for joining us here for the live Q&A. And again, thank you, Miguel. I'm going to stop the recording and then I'm going to copy the questions so that you have them and you want to follow up in the conveyor group on the Slack or however you want to take care of the rest. Really appreciate it. Yeah, all right, cool.